翻訳と辞書
Words near each other
・ Windows Security Log
・ Windows Server
・ Windows Server 2003
・ Windows Server 2008
・ Windows Server 2008 R2
・ Windows Server 2012
・ Windows Server 2016
・ Windows Server Essentials
・ Windows Server Update Services
・ Windows service
・ Windows Services for UNIX
・ Windows Setup
・ Windows shell
・ Windows Shell namespace
・ Windows SideShow
Windows software trace preprocessor
・ Windows Sound System
・ Windows Sources
・ Windows Speech Recognition
・ Windows startup process
・ Windows SteadyState
・ Windows Store
・ Windows Support Tools
・ Windows system
・ Windows System Assessment Tool
・ Windows System Resource Manager
・ Windows Task Scheduler
・ Windows tax
・ Windows Template Library
・ Windows thumbnail cache


Dictionary Lists
翻訳と辞書 辞書検索 [ 開発暫定版 ]
スポンサード リンク

Windows software trace preprocessor : ウィキペディア英語版
Windows software trace preprocessor

The Windows software trace preprocessor (abbreviated ''WPP''; the preprocessor and related support tools are known as ''WPP Software Tracing'') is a preprocessor that simplifies the use of WMI event tracing to implement efficient software tracing in drivers and applications that target Windows 2000 and later operating systems. WPP was created by Microsoft and is included in the Windows DDK. Although WPP is wide in its applicability, it is not included in the Windows SDK, and therefore is primarily used for drivers and driver support software produced by software vendors that purchase the Windows DDK.
==Background==

Software tracing is a specialized use of logging to record information about a program's execution. This information is commonly used for debugging. In contrast to ''event logging'', the primary purpose of which is to produce records of events that can be audited by system administrators (see for example ''Event Viewer'') or analyzed by management tools, software tracing is primarily a debugging aid for software developers. As such, many of the non-functional requirements of event logging, such as localizability or a standards-based output format, are explicitly non-goals for most applications of software tracing. On the other hand, software tracing has special requirements for performance that are not generally as important in event logging. For example, one common use of software tracing, ''in/out tracing'', produces output at the entry point and return of functions or methods so that a developer can visually follow the execution path, often including parameters and return values, in a debugger or text-based log file (this can be seen as a run-time analog of a sequence diagram). This type of tracing, although useful for developers, can greatly hurt performance of a software product if it cannot be disabled (either at compile-time via conditional compilation, or at run-time via flags).
Additional considerations special to software tracing include the following:
* In proprietary software, tracing data may include sensitive information about the product's source code.
* If tracing is enabled or disabled at run-time, many methods of tracing require a significant amount of additional data be included in the binary, which can indirectly hurt performance even when tracing is disabled.
* If tracing is enabled or disabled at compile-time, getting trace data for an issue on a customer machine depends on the customer being willing and able to install a special, tracing enabled, version of your software.
* Certain types of software, such as drivers, need to meet strict performance requirements even with tracing enabled.
Due to the first two considerations, traditional methods of software tracing use conditional compilation to enable or disable tracing (and inclusion of tracing data) at compile-time. For example, using the C preprocessor, one might define a macro DebugOut as follows:
#ifdef _DEBUG
#define DebugOut(msg, ...) \
DebugPrintf(__FUNCTION__ "(" __FILE__ ":" TO_STRING(__LINE__) ")\t" \
msg, __VAR_ARGS__)
#else
#define DebugOut(msg, ...)
#endif
where TO_STRING is a macro that converts the line number (__LINE__) to a string and DebugPrintf is a printf-like function that might for example output text to the debugger.
Then, the following code:
DebugOut("Error %d occurred\n", error_code);
would produce output similar to the following on debug builds only:
SomeFunction(file.c:78) Error 217 occurred
Another technique for certain types of tracing (particularly in/out tracing) is to use instrumentation. While this technique can address many of the major concerns, it is not always available (typically only in managed code).
WMI event tracing is an example of a technology that addresses in particular performance of tracing in performance-critical code such as drivers. It can also address the concern of controlling the distribution of sensitive trace information by letting a developer define the human-readable tracing data ("Error %d occurred\n" in the example above) separately from the code so that it is not built into the product (in the code, a specific message is referred to by its message number). However, there are some important limitations:
* WMI event tracing cannot, by itself, automatically generate the "SomeFunction(file.c:78)" part of the trace message. This is a limitation of all such technologies, not specific to WMI event tracing.
* Requiring the human-readable part of the tracing data to be separated from the code can decrease the readability of the code.
* Using this technique can introduce significant development overhead for "one-shot" tracing messages.

抄文引用元・出典: フリー百科事典『 ウィキペディア(Wikipedia)
ウィキペディアで「Windows software trace preprocessor」の詳細全文を読む



スポンサード リンク
翻訳と辞書 : 翻訳のためのインターネットリソース

Copyright(C) kotoba.ne.jp 1997-2016. All Rights Reserved.